If this is indeed the interface we want to provide to the end user, we may want to generate the variants automatically from a list of country codes instead of hardcoding them.

If instead we hardcode all codes like in this pull request, I wouldn't feel confident merging it unless we add a test that makes sure all flag.xy variants correspond to the right flag (i.e., the value of flag.xy is the sequence REGIONAL INDICATOR SYMBOL LETTER x + REGIONAL INDICATOR SYMBOL LETTER y).

@MDLC01 i have generated the ascii codes by subtracting a value from regional indicators. i can assure you all of them are correct. checking those, however, might be a good idea

Having it explicitly in the module source and having a test that runs an automatic check is indeed the way it should be done, and already has precedence with the variation selectors.

Something like \ri{x} meaning U+1F1FD : REGIONAL INDICATOR SYMBOL LETTER X ?

That way flag.us can be \ri{u} \ri{s}

This is also a possibility but it would be much more verbose, and still annoying to check manually. I think a test would be better.

This is also a possibility but it would be much more verbose, and still annoying to check manually. I think a test would be better.

I was thinking both.

That being said, isn't there some crate we can use as a source of truth about valid regional sequences? To avoid having to hard code everything.

@Enivex the unicode data:

https://www.unicode.org/Public/emoji/latest/emoji-sequences.txt

Interesting, I did not think Unicode provided an almost exhaustive list of flag sequences. Then I think it would be better to generate the flag variants automatically based on that.

Actually, the better way of doing it would be to have the flags be hard-coded but have a test that ensures all flags are valid, and all valid flags are present. This is consistent with the approach taken in #126 and it means we can keep Codex build-dependency-free.